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REHOMING AUTOMATION 

CROSS-REFERENCES TO RELATED APPLICATIONS 

This Application for Patent claims the benefit of priority from, and hereby 
5 incorporates by reference the entire disclosures of, co-pending U.S. Provisional 
Applications for Patent Serial Nos. 60/169,343, filed December 6, 1999, and 
60/202,616, filed May 9, 2000. 

BACKGROUND OF THE INVENTION 

10 Technical Field of the Invention 

The present invention relates in general to the telecommunications field and, 
in particular, to a method and system for automatically transferring mobile 
communications network base station data from one network controller to another. 
Description of Related Art 

1 5 One implementation of the so-called new 3 ,d generation mobile communication 

system is the Universal Mobile Telephone System (UMTS). In such a 3 rd generation 
system, rehoming is the task of moving a base station connection from one Radio 
Network Controller (RNC) to another. Basically, rehoming automation refers to the 
task of automatically transferring relevant radio network data and transport network 

20 data associated with a base station from a first RNC to a second RNC. Notably, 
although the concept of rehoming automation in a UMTS environment is discussed 
herein, the principles being discussed are also applicable for other types of cellular or 
mobile networks as well, such as, for example, Global System for Mobile 
Communications (GSM) networks, IS-95 networks, Digital-Advanced Mobile Phone 

25 System (D-AMPS) networks, etc. However, in such cases, the network information 
to be transferred from a first node to a second node can be passed, for example, via a 
Mobile Services Switching Center (MSC) and/or a management system. 

Rehoming is commonly accepted by many operators as an expedient method 
for expanding a network. For example, FIGURES 1 A-1C are related block diagrams 
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that illustrate how a rehoming procedure can be used to expand a network (e.g., the 
network associated with RNC2). 

A significant problem with existing rehoming procedures is that they involve 
some of the most labor intensive Operation & Maintenance (O&M) functions that 
5 network operators can perform. The main reason for this problem is that the existing 
rehoming procedures followed for routing base station data from one RNC (or other 
such entity) to another RNC are accomplished manually. In other words, using the 
existing rehoming procedures, a network operator has to manually provide all data 
associated with a base station to a new RNC and then manually delete the base station- 
1 0 related data from the original RNC. These manual rehoming approaches significantly 
increase the O&M time and associated costs for operators, and also increase the 
likelihood that errors will be introduced. 

SUMMARY OF THE INVENTION 
15 In accordance with a preferred embodiment of the present invention, an 

automated rehoming method and system are provided, whereby all pertinent data (e.g., 
all radio network data and transport network data pertaining to a base station) are 
conveyed in one or more messages from a first RNC to a second RNC via, for 
example, an Iur, Iu or management interface, or via any proprietary (standard or non- 
20 standard) interface for other, 3 rd or non-3 Td generation systems, and establish a 
connection between the second RNC and a Node B. 

An important technical advantage of the present invention is that by 
automating the rehoming procedure, the associated O&M time and costs can be 
significantly reduced. 

25 Another important technical advantage of the present invention is that the 

probability of reducing errors during the rehoming procedure can be significantly 
reduced. 



30 
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BRIEF DESCRIPTION OF THE DRAWINGS 

A more complete understanding of the method and apparatus of the present 
invention may be had by reference to the following detailed description when taken 
in conjunction with the accompanying drawings wherein: 
5 FIGURES 1A-1C are related block diagrams that illustrate how a rehoming 

procedure can be used to expand a network; 

FIGURE 2 is a block diagram of a 3 rd generation mobile communication 
network, which can be used to implement a preferred embodiment of the present 
invention; 

10 FIGURES 3 A, 3B and 3C are related block diagrams of a 3 rd generation mobile 

communication system, which can be used to implement the preferred embodiment 
of the present invention if a rehoming procedure is fully or partly successful, or 
unsuccessful; 

FIGURE 4 is a time sequence diagram that illustrates an example of a 
15 successfully performed rehoming procedure, in accordance with the preferred 
embodiment of the present invention; 

FIGURE 5 is a time sequence diagram that illustrates a second example of a 
successfully performed rehoming procedure, in accordance with the preferred 
embodiment of the present invention; 
20 FIGURE 6 is a time sequence diagram that illustrates a third example of a 

successfully performed rehoming procedure, in accordance with the preferred 
embodiment of the present invention; 

FIGURE 7 is a time sequence diagram that illustrates an example of an 
unsuccessful rehoming procedure, in accordance with the preferred embodiment of the 
25 present invention; 

FIGURE 8 is a time sequence diagram that illustrates a second example of an 
unsuccessful rehoming procedure, in accordance with the preferred embodiment of the 
present invention; and 

FIGURE 9 is a time sequence diagram that illustrates a third example of an 
30 unsuccessful rehoming procedure, in accordance with the preferred embodiment of the 
present invention. 
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DETAILED DESCRIPTION OF THE DRAWINGS 

The preferred embodiment of the present invention and its advantages are best 
understood by referring to FIGURES 1 A-9 of the drawings, like numerals being used 
for like and corresponding parts of the various drawings. 

5 Essentially, in accordance with a preferred embodiment of the present 

invention, an automated rehoming method and system are provided, whereby all 
pertinent data (e.g., all radio network data and transport network data pertaining to a 
base station) are conveyed in one or more messages from a first RNC to a second 
RNC via, for example, an Iur, lu or management interface, or via any proprietary 

10 (standard or non-standard) interface for other, 3 rd or non-3 rd generation systems, and 
establish a connection between the second RNC and a Node B. As such, the present 
invention is independent of the underlying transport network technology used for 
signalling and data transport. The transport networks involved can include circuit- 
switched transport networks, packet-switched transport networks, or any type of 

15 transport network such as, for example, an ATM transport network, an IP transport 
network, a CCS7 transport network, etc. 

Specifically, FIGURE 2 is a block diagram of an exemplary mobile 
communication network such as, for example, a 3 rd generation mobile communication 
network, which can be used to implement a preferred embodiment of the present 

20 invention. Referring to FIGURE 2, a Universal Mobile Telephony System (UMTS) 
10 configured in accordance with the 3* Generation Partnership Project (3 GPP) 
technical specifications is shown. The exemplary UMTS 10 shown includes a Core 
* Network 12, and a Universal Terrestrial Radio Access Network (UTRAN) 11 
including one or more Radio Network Subsystems (RNSs), such as RNSs 13a and 

25 13b. The Core Network 12 enables subscribers to access services from a network 
operator. Also, for this example, the RNSs shown include respective RNCs 14a, 14b 
and related Node Bs 16a, 16b, 16c, 16d. 

Specifically, an RNS (e.g., 13a or 13b) can function in a UTRAN as, for 
example, the access part of a UMTS network, and can allocate and release specific 

30 radio resources in order to establish connections between a UTRAN (e.g., 11) and a 
radio terminal (User Equipment or UE) 18. As such, an RNS is responsible for the 
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radio resources and transmission/reception in a set of cells. The RNCs (e.g., 14a, 14b) 
in the respective RNSs function to control the use and integrity of the radio resources. 
Each Node B (e.g., 16a, 16b, 16c, 16d) is a logical node responsible for the radio 
transmission/reception in one or more cells and to or from a UE (e.g., 18). A Node 
B is similar to a base station in a non-3 rd generation system. Notably, an RNC (e.g., 
1 4b) can function as a Controlling RNC (CRNC) with respect to a specific set of Node 
Bs. However, a Node B typically has only one CRNC. A CRNC controls the logical 
resources of its related Node Bs. 

In accordance with the embodiment exemplified by FIGURE 2, two types of 
network data are involved during the rehoming procedure: radio network data and 
transport network data. The radio network data includes all data configured in a base 
station received from a CRNC preferably over an Iub interface. Such radio network 
data can be derived from certain procedures such as, for example, cell setup, cell 
reconfiguration, common transport channel setup, common transport channel 
reconfiguration, system information update, common measurements initiation, and 
resource status indication procedures. The radio network data can also include 
neighboring cell information stored in a CRNC for all cells configured in the base 
station which is to be moved (connected) to another RNC. A detailed listing of the 
radio network data used for a 3 ld generation system is disclosed in the UTRAN 
Technical Specification TS 25.433 (UTRAN Iub Interface NBAP Signalling from 
3 GPP). 

The transport network data can include transport layer addresses, link 
characteristics, and other transport layer-related data needed to establish transport 
bearers used for carrying user plane data between a new RNC and a base station. For 
example, this data can be ATM endpoint addresses, peak/average bit rates, etc., in an 
ATM-based transport network. 

If necessary, in accordance with the preferred embodiment of the present 
invention, new radio network configuration data which has not been used by a first 
and second RNC, can be. sent from the management system to the first and second 
RNC. Also, new radio network configuration data can be sent from the management 
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system to the first RNC, which can then send the data in a container message to the 
first and second RNC. 

Specifically, FIGURES 3A, 3B and 3C are related block diagrams of an 
exemplary 3 rd generation mobile communication system 100, which can be used to 
5 implement the preferred embodiment of the present invention, if an attempted 
automated rehoming procedure is fully successful, partly successful, or unsuccessful 
As shown in FIGURES 3 A, 3B and 3C, the exemplary system 100 includes a 
management system 102, a first RNC 1 04, a second RNC 1 06, and a base station BS2 
1 08. As such, the management system 102 performs network management functions 

10 and provides a management interface with an operator. 

In operation, referring to FIGURE 3A, the (automated) rehoming procedure 
to be performed is initiated by a control message (denoted by 103) from the 
management system 102. The control message orders RNC1 104 to take all cells 
supported by BS2 1 08 out of operation, and place all relevant radio network and 

15 transport network data regarding BS2 108, which is to be used by RNC2 106, into one 
or more container messages. RNC1 104 then sends the one or more container 
message(s) to RNC2 106 via the Iur interface (denoted by 105), before BS2 108 is 
moved and connected to RNC2 106. As such, all relevant configuration data remains 
unchanged in BS2 108 during the rehoming procedure. Any required reconfiguration 

20 of the transport network and signalling network can be accomplished before initiating 
the rehoming procedure. However, the transport bearers to be used for carrying user 
plane data between BS2 1 08 and RNC2 1 06 can be pre-configured prior to rehoming, 
or dynamically established during a rehoming procedure. 
' Referring to FIGURE 3B, RNC2 1 06 then performs an audit procedure via the 

25 Iub interface to ensure that it has the same radio network configuration information 
as BS2 1 08 (denoted by 107). If the audit procedure's results are correct, RNC2 1 06 
sends a response message to RNC1 104 via the Iur interface, which causes RNC1 to 
delete its data about BS2 108 (denoted by 109). RNC1 104 and/or RNC2 106 sends 
a message to the management system 102 via a management interface 111a and/or 

30 111b, which informs the management system that the rehoming procedure was 
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successfully completed. The management system 1 02 then notifies the operator (1 1 3) 
that the rehoming procedure was successfully completed. 

In the event that the rehoming procedure was only partially successful, the 
operator can decide whether.to complete the rehoming procedure with the degraded 
5 performance, or perform a rollback procedure (return to the original configuration). 
Such a decision can be made by the operator on-line (e.g., in real-time) or 
implemented and so configured before the rehoming procedure is performed. In any 
event, the decision about whether to complete a degraded performance rehoming 
procedure or perform a rollback procedure, can be configured by the management 
1 0 system 1 02 so that for certain circumstances, the operator can make the decision on- 
line. For example, if the Broadcast Channel (BCH) cannot be supported by the 
rehoming procedure, the operator can decide that a rollback procedure is to be 
performed. As another example, if less than 50% of the transport bearers required for 
the Fast Acquisition Channel (FACH), Paging Channel (PCH), and/or Random Access 
1 5 Channel (RACH) can be established, the operator can make the decision on-line about 
whetherto complete the rehoming procedure orperform a roll-back procedure. As yet 
another example, if more than 50% of the transport bearers required for the FACH, 
PCH, and/or RACH can be established, then the operator can decide on-line that the 
rehoming procedure is to be completed. As such, it should be understood that there 
20 are a number of reasons, other than a shortage of transport bearers, why an operator 
might decide to terminate the rehoming procedure. For example, an operator might 
terminate a rehoming procedure if certain internal RNC errors were to occur, or there 
is a shortage of processor or memory capacity in an RNC. 

In the event a significant error occurs during the rehoming procedure, a 
25 rollback procedure can be performed. For example, referring to FIGURE 3C, during 
the above-described rehoming procedure, if the transport bearers between BS2 108 
and RNC2 106 cannot be established for all PCHs, or some other error occurs that 
results in an unsuccessful rehoming procedure, BS2 108 can be moved back 
(connected) to RNC1 104. As such, RNC2 106 releases all of its newly established 
30 transport bearers to BS2 108(11 5) via the Iub interface, before RNC2 1 06 informs 
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RNC1 104 that the rehoming attempt has failed (117). RNC2 106 deletes the 
pertinent data previously received in container message(s) from RNC1 104. 

In response, RNC1 104 initiates an audit procedure for (or can send a 
Rehoming Failure message to) BS2 108 via the Iub interface (119), in order to re- 
5 establish the connection between RNC 1 1 04 and BS2 1 08, and ensure that RNC1 1 04 
and BS2 1 08 have the same opinion about the configuration in BS2 108. RNC1 104 
then informs the management system 102 that the rehoming procedure attempt was 
unsuccessful. BS2 108 is connected back to RNC1 104 (121). The management 
system 102 then notifies the operator (123) that the rehoming procedure attempt has 
10 failed. 

In accordance with the existing UMTS standard, the RNC can perform an audit 
procedure to determine whether both nodes (e.g., RNC and base station) have the 
same opinion about the configuration of the base station. This audit procedure can be 
performed due to a break in communications between the base station and an RNC. 

1 5 If the two nodes' opinions differ, then the RNC can take appropriate actions until the 
differences are resolved and consistent opinions about the configuration of the base 
station are formed by the two nodes. 

FIGURE 4 is a time sequence diagram that illustrates an example of a 
successfully performed rehoming procedure, in accordance with the preferred 

20 embodiment of the present invention. Referring to the system shown in FIGURE 3A, 
and the method 150 shown in FIGURE 4, at step 152, the management system 102 
sends a rehoming request message to RNC 1 104 via the management interface. In 
response, at step 1 54, RNC1 1 04 sends a rehoming request message to RNC2 1 06 via 
the lur interface. This rehoming request message includes pertinent radio network and 

25 transport network data. 

At step 1 56, RNC2 106 sends an audit request message to BS2 1 08 via the Iub 
interface. This audit request message indicates to BS2 108 that a rehoming attempt 
to RNC2 106 is to be performed. In response, at step 158, BS2 108 sends an audit 
response message to RNC2 106 via the Iub interface. This audit response message 

30 includes the Binding IDs for the transport bearers that RNC2 106 is to use. At step 
160, RNC2 106 establishes the transport bearers for the common transport channels 



BNSDOCIO: <WO 0l<M493AlJ_> 



WO 01/41493 



PCT/SE00/02354 



-9- 

to be used. When RNC2 106 has established the required transport bearers, at step 
162, RNC2 sends an audit complete message (e.g., a new Node B Application 
Protocol (NBAP) message within the UMTS specification) to BS2 108 via the Iub 
interface, which informs BS2 that the newly established transport bearers are to be 
used. 

At step 164,RNC2 1 06 sends a rehoming response message to RNC1 104 via 
the Iur interface. In response, at step 166, RNC1 104 releases the transport bearers 
used between RNC1 andBS2 108. The radio network data and transport network data 
forBS2 108 should be deleted in RNC1 104 after the release. At step 168,RNC1 104 
sends a rehoming response message to the management system 102 via the 
management interface, which informs the management system that the rehoming 
procedure has been successfully completed. 

FIGURE 5 is a time sequence diagram that illustrates a second example of a 
successfully performed rehoming procedure, in accordance with the preferred 
embodiment of the present invention. Referring again to the system shown in 
FIGURE 3 A, and the method 1 70 shown in FIGURE 5, at step 1 72, the management 
system 102 sends a rehoming request message to RNC1 104 via the management 
interface. In response, at step 1 74, RNC1 1 04 sends an audit request message to BS2 
108 via the Iub interface. This audit request message indicates to BS2 108 that a 
rehoming attempt to RNC2 106 is to be performed. In response, at step 1 76, BS2 1 08 
sends an audit response message to RNC1 104 via the Iub interface. This audit 
response message includes the Binding IDs for the transport bearers that RNC2 106 
is to use. At step 1 78, RNC I 1 04 sends a rehoming request message to RNC2 1 06 via 
the Iur interface. This rehoming request message includes radio network data with the 
Binding IDs for the transport bearers RNC2 1 06 is to use, and transport network data. 

At step 180, RNC2 106 establishes the transport bearers for the common 
transport channels to be used. When RNC2 1 06 has established the required transport 
bearers, at step 182, RNC2 sends an audit request message to BS2 108 via the Iub 
interface. The primary purpose of this audit request message is to ensure that the two 
nodes (RNC2 and BS2) have the same opinion about the configuration in BS2. In 
response, at step 1 84, BS2 1 08 sends an audit response message to RNC2 1 06 via the 
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Iub interface. For this example, it can be assumed that this audit response message 
indicates that the two nodes' opinions are consistent about the configuration in BS2 
108. 

At step 1 86, RNC2 106 sends a rehoming response message to RNC 1 1 04 via 

5 the lur interface. This rehoming response message indicates to RNC1 1 04 that the 
rehoming procedure was successfully performed. At step 188, RNC1 104 sends an 
audit complete message to BS2 108 (e.g., anew NBAP message) via the Iub interface. 
This audit complete message indicates to BS2 108 that the new transport bearers to 
RNC2 106 are to be used. In response, at step 190, RNC1 104 releases the transport 

1 0 bearers used between RNC 1 and BS2 1 08. At step 1 92, RNC 1 1 04 sends a rehoming 
response message to the management system 1 02 via the management interface. This 
rehoming response message informs the management system 102 that the rehoming 
procedure has been successfully completed. 

FIGURE 6 is a time sequence diagram that illustrates a third example of a 

15 successfully performed rehoming procedure, in accordance with the preferred 
embodiment of the present invention. Referring again to the system shown in 
FIGURE 3 A, and the method 200 shown in FIGURE 6, at step 202, the management 
system 102 sends a rehoming request message to RNC1 104 via the management 
interface. In response, at step 204, RNC1 104 sends a rehoming request message to 

20 BS2 1 08 via the Iub interface, which indicates to BS2 1 08 that a rehoming attempt to 
RNC2 106 is to be performed (e.g., a new NBAP message). At step 206, BS2 108 
sends a rehoming response message to RNC1 104 via the Iub interface. This 
rehoming response message includes the Binding IDs for the transport bearers that 
RNC2 106 is to use (e.g., a new NBAP message). In response, at step 208, RNC 1 104 

25 sends a rehoming request message to RNC2 1 06 via the lur interface. This rehoming 
request message includes radio network data with the Binding IDs for the transport 
bearers RNC2 106 is to use, and transport network data. 

At step 210, RNC2 106 establishes the transport bearers for the common 
transport channels to be used. When RNC2 1 06 has established the required transport 

30 bearers, at step 212, RNC2 sends an audit request message to BS2 108 via the Iub 
interface. The primary purpose of this audit request message is to ensure that the two 
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nodes (RNC2 and BS2) have the same opinion about the configuration in BS2 108. 
In response, at step 214, BS2 108 sends an audit response message to RNC2 106 via 
the Iub interface. For this example, it can be assumed that this audit response message 
indicates that the two nodes 1 opinions are consistent about the configuration in BS2 
5 108. 

At step 216, RNC2 1 06 sends a rehoming response message to RNC 1 1 04 via 
the Iur interface. This rehoming response message indicates to RNC1 104 that the 
rehoming procedure was successfully performed. At step 218, RNC1 104 sends a 
rehoming complete message to BS2 108 via the Iub interface (e.g., a new NBAP 

10 message). This rehoming complete message informs BS2 108 that the transport 
bearers to RNC2 106 are to be used. In response, at step 220, RNC 1 104 releases the 
transport bearers used between RNC1 and BS2 108. At step 222, RNC1 104 sends 
a rehoming response message to the management system 102 via the management 
interface. This rehoming response message informs the management system 1 02 that 

1 5 the rehoming procedure has been successfully completed. 

FIGURE 7 is a time sequence diagram that illustrates an example of an 
unsuccessful rehoming procedure, in accordance with the preferred embodiment of the 
present invention. Referring to the system shown in FIGURE 3C, and the method 230 
shown in FIGURE 7, at step 232, the management system 102 sends a rehoming 

20 request message to RNC 1 1 04 via the management interface. In response, at step 234, 
RNC1 104 sends a rehoming request message to RNC2 106 via the Iur interface. This 
rehoming request message includes pertinent radio network and transport network 
data. 

At step 236, RNC2 1 06 sends an audit request message to BS2 1 08 via the Iub 
25 interface. This audit request message indicates to BS2 108 that a rehoming attempt 
to RNC2 106 is to be performed. In response, at step 238, BS2 108 sends an audit 
response message to RNC2 106 via the Iub interface. This audit response message 
includes the Binding IDs for the transport bearers that RNC2 106 is to use. 

At step 240, RNC2 106 attempts to establish the transport bearers for the 
30 common transport channels to be used between RNC2 and BS2 1 08 . Assuming, for 
this example, that only one transport bearer (e.g., out of five) can be established, at 
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step 241, the rehoming attempt is considered unsuccessful (by data configured in 
RNC2 106). Consequently, at step 242, RNC2 106 releases the newly established 
transport bearer. At step 244, RNC2 106 sends a rehoming response message to 
RNC 1 1 04 via the Iur interface. This rehoming response message indicates to RNC1 
5 1 04 that the rehbming attempt failed. At step 246, RNC 1 1 04 sends an audit request 
message to BS2 108 via the Iub interface, in order to determine the state of the 
configuration in BS2 108, and rollback the original transport bearers between RNC1 
104 and BS2 108. At step 248, BS2 108 sends an audit response message to RNC1 
104 via the Iub interface, which indicates to RNC1 104 that the requested audit has 

10 been performed. At step 250, RNC1 104 sends a rehoming response message to the 
management system 102 via the management interface. This rehoming response 
message informs the management system that the rehoming attempt failed. 

FIGURE 8 is a time sequence diagram that illustrates a second example of an 
unsuccessful rehoming procedure, in accordance with the preferred embodiment of the 

15 present invention. Referring again to the system shown in FIGURE 3C, and the 
method 260 shown in FIGURE 8, at step 262, the management system 102 sends a 
rehoming request message to RNC1 104 via the management interface. In response, 
at step 264, RNC1 104 sends an audit request message to BS2 108 via the Iub 
interface. This audit request message indicates to BS2 108 that a rehoming attempt 

20 to RNC2 106 is to be performed (e.g., a new NBAP message). In response, at step 
266, BS2 108 sends an audit response message to RNC1 104 via the Iub interface. 
This audit response message includes the Binding IDs for the transport bearers that 
RNC2 106 is to use. At step 268, RNC1 104 sends a rehoming request message to 
RNC2 106 via the Iur interface. This rehoming request message includes radio 

25 network data with the Binding IDs for the transport bearers RNC2 is to use, and 
transport network data. 

At step 270, RNC2 106 establishes the transport bearers for the common 
transport channels to be used to BS2 108. When RNC2 106 has established the 
required transport bearers, at step 272, RNC2 sends an audit request message to BS2 

30 108 via the Iub interface. The primary purpose of this audit request message is to 
ensure that the two nodes (RNC2 and BS2) have the same opinion about the 
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configuration in BS2. In response, at step 274, BS2 108 sends an audit response 
message to RNC2 1 06 via the Iub interface. For this example, it can be assumed that 
this audit response message indicates that the BCH, primary and secondary SCHs, and 
the primary and secondary CPICH were not operable, and a criterion configured in 
5 RNC2 106 for a failed rehoming attempt is that a BCH is not operable. In other 
words, this rehoming attempt has failed (step 276). Consequently, at step 278, RNC2 
106 releases the newly established transport bearers to BS2 108. At step 280, RNC2 
106 sends a rehoming response message to RNC1 104 via the Iur interface. This 
rehoming response message indicates to RNC1 1 04 that the rehoming attempt failed. 

1 0 At step 282, RNC 1 1 04 sends an audit complete message (e.g., a new NBAP message) 
to BS2 108 via the Iub interface. This audit complete message informs BS2 108 that 
the original transport bearers to RNC1 104 are to be rolled back (restored). At step 
284, RNC1 104 sends a rehoming response message to the management system 102 
via the management interface. This rehoming response message informs the 

15 management system that the rehoming attempt failed. 

FIGURE 9 is a time sequence diagram that illustrates a third example of an 
unsuccessful rehoming procedure, in accordance with the preferred embodiment of the 
present invention. Referring again to the system shown in FIGURE 3C, and the 
method 300 shown in FIGURE 9, at step 302, the management system 102 sends a 

20 rehoming request message to RNC1 104 via the management interface. In response, 
at step 304, RNC1 104 sends a rehoming request message to BS2 108 via the Iub 
interface, which indicates to BS2 108 that a rehoming attempt to RNC2 106 is to be 
performed (e.g., a new NBAP message). At step 306, BS2 108 sends a rehoming 
response message to RNC1 104 via the Iub interface (e.g., a new NBAP message). 

25 This rehoming response message includes the Binding IDs for the transport bearers 
that RNC2 106 is to use. In response, at step 308, RNC1 104 sends a rehoming 
request message to RNC2 106 via the Iur interface. This rehoming request message 
includes radio network data with the Binding IDs for the transport bearers RNC2 1 06 
is to use, and transport network data. 

30 At step 310, RNC2 106 establishes the transport bearers for the common 

transport channels to be used to BS2 108. When RNC2 106 has established the 
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required transport bearers, at step 312, RNC2 sends an audit request message to BS2 
108 via the Iub interface. The primary purpose of this audit request message is to 
ensure that the two nodes (RNC2 and BS2) have the same opinion about the 
configuration in BS2 108. In response, at step 314, BS2 108 sends an audit response 
5 message to RNC2 1 06 via the Iub interface. For this example, it can be assumed that 
this audit response message indicates that the BCH, primary and secondary SCHs, and 
primary and secondary CPICH are not operable, and a criterion configured in RNC2 
106 for a failed rehoming attempt is a non-operable BCH. In other words, this 
rehoming attempt failed (step 316). At step 318, RNC2 106 releases the newly 

1 0 established transport bearers to BS2 1 08, and at step 320, sends a rehoming response 
message to RNC 1 1 04 via the Iur interface. This rehoming response message informs 
RNC1 104 that the rehoming attempt failed. At step 322, RNC1 104 sends a 
rehoming failure message to BS2 108 (e.g., a new NBAP message), which informs 
BS2 that the original transport bearers to BS2 108 are to be rolled back (restored). At 

15 step 324, RNC1 1 04 sends a rehoming response message to the management system 
102 via the management interface. This rehoming response message informs the 
management system that the rehoming attempt failed. 

Although a preferred embodiment of the method and apparatus of the present 
invention has been illustrated in the accompanying Drawings and described in the 

20 foregoing Detailed Description, it will be understood that the invention is not limited 
to the embodiment disclosed, but is capable of numerous rearrangements, 
modifications and substitutions without departing from the spirit of the invention as 
set forth and defined by the following claims. 
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WHAT IS CLAIMED IS: 

1 . A rehoming method for a mobile communication system, comprising 

the steps of: 

informing a first network control unit to remove from operation at least one 
5 cell generated by a base station; 

inserting radio network data associated with a connection between a second 
network control unit and said base station in at least one container message; 

sending said at least one container message to said second network control 
unit; and 

10' establishing said connection between said base station and said second 

network control unit. 

2. The rehoming method of Claim 1, further comprising the step of 
determining if said second network control unit and said base station agree about a 

1 5 radio network configuration for said base station. 

3. The method of Claim 2, further comprising the steps of: 

if said second network control unit and said base station agree about a radio 
network configuration for said base station, said second network control unit sending 
20 a confirmation message to said first network control unit; and 

said first network control unit deleting connection data associated with said 
base station. 

4. The method of Claim 2, further comprising the steps of: 

25 if said second network control unit and said base station do not agree about a 

radio network configuration for said base station, instead of establishing said 
connection between said base station and said second network control unit, 
establishing a connection between said base station and said first network control unit. 



30 



5. The method of Claim 2, further comprising the steps of: 
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if said second network control unit and said base station do not agree about a 
radio network configuration for said base station, establishing said connection 
between said base station and said second network control unit. 

5 6. The method of Claim 1 , wherein the inserting step and sending step are 

performed by said first network control unit. 

7. The method of Claim 1 , wherein the step of sending said at least one 
container message to said second network control unit comprises sending said at least 

1 0 one container message to said second network control unit via an Iur interface. 

8. The method of Claim 1, wherein the step of informing a first network 
control unit to remove from operation at least one cell generated by a base station 
comprises a management system instructing said first network control unit to remove 

15 from operation said at least one cell generated by said base station. 

9. The method of Claim 1 , further comprising the step of establishing at 
least one transport bearer to be used for said connection between said base station and 
said second network control unit. 

20 

10. The method of Claim 1 , wherein the step of determining if said second 
network control unit and said base station agree about a radio network configuration 
for said base station comprises a step of initiating an audit procedure. 

25 11. The method of Claim 1 , wherein said mobile communication system 

comprises a UMTS. 

12. The method of Claim 1, wherein if a connection performance between 
said second network control unit and said base station is less than a predetermined 
30 level, instead of establishing said connection between said base station and said 
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second network control unit, re-establishing a connection between said base station 
and said first network control unit. 

13. The method of Claim 12, wherein the step of re-establishing said 
5 connection between said base station and said first network control unit comprises 

performing a rollback procedure. 

1 4. The method of Claim 9, wherein if the step of establishing said at least 
one transport bearer to be used for said connection between said base station and said 

10 second network control unit is unsuccessful, said second network control unit 
releasing any established transport bearer to be used for said connection between said 
base station and said second network control unit, and informing said first network 
control unit that a rehoming attempt has failed. 

15 15. The method of Claim 1, wherein said first network control unit and 

said second network control unit comprise a first radio network controller and a 
second radio network controller, respectively. 

16. The method of Claim 1 , wherein the inserting step further comprises 
20 inserting transport network data associated with said connection in said at least one 

container message. 

17. An automated rehoming system for a mobile communication system, 
comprising: 

25 a base station; 

a first network control unit, said firstnetwork control unit operable to establish 
a first radio connection with said base station; 

a second network control unit, said second network control unit operable to 
establish a second radio connection with said base station; and 
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a network interface, said network interface operable to establish a signalling 
connection with at least one of said base station, said first network control unit, and 
said second network control unit, said network interface further operable to: 

instruct said first network control unit to remove from operation at least one 
5 cell generated by said base station; and 

said first radio network control unit further operable to: 
insert radio network data associated with said second radio connection 
between said second network control unit and said base station in at least one 
container message; and 
1 0 send said at least one container message to said second network control unit; 

said second radio network control unit further operable to: 
establish said radio connection between said base station and said second 
network control unit. 

15 18. The automated rehoming system of Claim 17, said system further 

operable to determine if said second network control unit and said base station agree 
about a radio network configuration for said base station. 

19. The automated rehoming system of Claim 18, said second network 
20 control unit further operable to send a confirmation message to said first network 
control unit if said second network control unit and said base station agree about a 
radio network configuration for said base station, said first network control unit 
further operable to delete connection data associated with said base station. 

25 * 20. The automated rehoming system of Claim 1 8, said first network control 

unit further operable to establish a connection between said base station and said first 
network control unit if said second network control unit and said base station do not 
agree about a radio network configuration for said base station. 

30 21. The automated rehoming system of Claim 18, said second network 

control unit further operable to establish said connection between said base station and 
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said second network control unit if said second network control unit and said base 
station do not agree about a radio network configuration for said base station. 

22. The automated rehoming system of Claim 17, wherein said first 
5 network control unit is further operable to send said at least one container message to 

said second network control unit via an Iur interface. 

23. The automated rehoming system of Claim 17, wherein said 
management system is further operable to instruct said first network control unit to 

10 remove from operation said at least one cell generated by said base station. 

24. The automated rehoming system of Claim 17, said second network 
control unit further operable to establish at least one transport bearer to be used for 
said connection between said base station and said second network control unit. 

15 

25. The automated rehoming system of Claim 17, wherein said second 
network control unit is further operable to initiate an audit procedure if said second 
network control unit and said base station agree about a radio network configuration 
for said base station. 

20 

26. The automated rehoming system of Claim 17, wherein said mobile 
communication system comprises a UMTS. - 

27. The automated rehoming system of Claim 17, wherein said first 
25 network control unit is further operable to re-establish a connection between said base 

station and said first network control unit if a connection performance between said 
second network control unit and said base station is less than a predetermined level. 

28. The automated rehoming system of Claim 27, wherein said first 
30 network control unit is further operable to re-establish said connection between said 

base station and said first network control unit by performing a rollback procedure. 
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29. The automated rehoming system of Claim 24, wherein said second 
network control unit is farther operable to release any established transport bearer to 
be used for said connection between said base station and said second network control 
unit, and inform said first network control unit that a rehoming attempt has failed, if 

5 an attempt to establish said at least one transport bearer to be used for said connection 
between said base station and said second network control unit is unsuccessful. 

30. The automated rehoming system of Claim 17, wherein said first 
network control unit and said second network control unit comprise a first radio 

10 network controller and a second radio network controller, respectively. 

3 1 . The automated rehoming system of Claim 1 7, wherein said first radio 
network control unit is further operable to insert transport network data associated 
with said second radio connection in said at least one container message. 

15 
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